Case Study:
Nautilus Test System

System Overview

Damon Cokenias of the ODF team needed to design a system for testing various parts of OpenDoc and ODF. He decided, of course, to use the power of component software to solve the problem. The system he developed is code-named Nautilus, and can actually be used to test nearly any set of APIs. It consists of the following components, as shown in the diagrams below:

• Nautilus container, which provides an environment for assembling test cases, running the tests, and logging the results.
  
  
• List parts embedded in the container. These provide scrolling text lists needed by the Nautilus container. These lists could have been hard-coded as part of the container, but there are two virtues in having the lists be separate leaf parts. First, they could be (and were) written by someone else. Second, they can be replaced by better list parts as they are developed.
  
  
• Plug-in test parts, dropped into the container. Each one of these plug-ins contains the details for running specific tests on various parts of the system being tested. These plug-ins have a minimal user interface. They have no display frames, menus, dialogs, or user event handling. The only thing the user can see of each installed plug-in is its Finder icon, which can be unique for each plug-in. The plug-ins architecture was chosen to make it easy for other programmers to learn to design new test parts.

Nautilus editors and SOM libraries

Technologies Used: Embedding and Extensions

• Embedding. As you can see in the screen shot above, embedding is necessary to integrate the separate parts into a single document. A neat trick in this case is that the Nautilus container document automatically creates and loads the two list parts, so that the user does not have to do that.
  
  
• Extensions. Each of the embedded Test parts contains information about a particular set of tests. Since the container must start the tests and log the results, the container must communicate with each of the embedded test parts. This communication is managed by an OpenDoc extension which must be implemented in each test part. The container gets the extension object for each test part, and calls its functions to control the tests.

Class diagram for extension classes

Programming Overview

• Plug-in Extensions.
  Each test plug-in must subclass a SOM class called SOMNautilusPluginExtension, and override the following five methods:
  • Hello() is called once by the Nautilus container when it opens communication with the plug-in.
  • Goodbye() is called once by the Nautilus container just before it disconnects from the plug-in.
  • CountTestCases() is called to determine the number of tests found in any plug-in.
  • GetTestCase() returns a SOM object describing the a test case referenced by an index.
  • ExecuteTestCase() executes a specific test case.
    
    
• Nautilus Extensions.
  The Nautilus container provides seven methods in the OpenDoc extension of class SOMNautilusShellExtension that can be called by any connected plug-in part. These include:
  • Hello() is called by the plug-in in response to Nautilus calling the plug-in's Hello() method.
  • Goodbye() is called by the plug-in in response to Nautilus calling the plug-in's ReleaseAll() method.
  • Verify() is called by the plug-in to verify the results of an API call.
  • YieldTime() should be called during time-consuming tasks to insure a responsive user interface.
    

Real Files

• The 1.0 d5 release of the Nautilus part editors, SOM libraries, stationery, and Programmer's Guide are provided in a StuffIt archive. Later releases are likely to be available on the Web.